home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 1421 < prev    next >
Encoding:
Text File  |  1996-08-05  |  5.0 KB  |  121 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: FreeNet.Carleton.CA!an171
  3. From: an171@FreeNet.Carleton.CA (Anthony Hill)
  4. Subject: Re: USR Courier not really V.Everything?
  5. Message-ID: <DL56Jr.75p@freenet.carleton.ca>
  6. Sender: an171@freenet5.carleton.ca (Anthony Hill)
  7. Reply-To: an171@FreeNet.Carleton.CA (Anthony Hill)
  8. Organization: The National Capital FreeNet
  9. References: <4d6b45$g1v@power.ci.uv.es> <teddyburDL4L5q.K9t@netcom.com>
  10. Date: Sat, 13 Jan 1996 22:59:51 GMT
  11.  
  12.  
  13. John Sanger (teddybur@netcom.com) writes:
  14. > In article <4d6b45$g1v@power.ci.uv.es> hmr@iluso.ci.uv.es (Hector M. Rulot Segovia) writes:
  15. >> We have a pool of 4 USR Courier modems, to receive incoming connections.
  16. >>
  17. >> They work fine, and accept connections for -almost- every modem, but,
  18. >> and this is the problem, some modems (of many different brands) seems
  19. >> unable to establish a connection with the Couriers, and always returns the
  20. >> "NO CARRIER" message after some dialog. Note that these modems (most of
  21. >> them 14400 bauds modems) works fine when connecting with other providers.
  22. >> 
  23. >> We buy the Couriers hoping to avoid these compatibility problems, and
  24. >> still I am not sure that this is not a configuration problem. Anyone
  25. >> has any idea?.
  26. >> 
  27. >> Many anticipated thanks,                    Hector
  28. >> 
  29. >> 
  30. >> PD:
  31. >> This is the configuration of our Couriers:
  32. >> 
  33. >> <<
  34. >> USRobotics Courier V.32bis Dual Standard V.34 Fax NVRAM Settings...
  35. >>
  36. >>   DIAL=PULSE  B0  F1  M1  X7
  37. >>   BAUD=115200 PARITY=N  WORDLEN=8
  38. >>
  39. >>   &A0  &B1  &G2  &H1  &I0  &K1  &L0  &M4  &N0
  40. >>   &P1  &R2  &S0  &T5  &X0  &Y1  %N6
  41. >>
  42. >>   S00=001  S02=043  S03=013  S04=010  S05=008  S06=002  S07=060  S08=002
  43.           ^^^^^^^
  44.     You should really change this if you're using the modems to
  45. recieve calls.  it won't affect performance in any way, but it will
  46. prevent people from dropping your modem into command mode (and being
  47. forced to drop the connection) any time they try to drop their own modems
  48. into command mode.  Set S2=255.
  49.  
  50.  
  51. >>   S09=006  S10=015  S11=070  S12=050  S13=000  S15=000  S19=020  S21=010
  52.  
  53.     You may also want to set S13=1, this will tell the modem to reset
  54. on DTR drop, may prevent occasional modem lock ups.
  55.  
  56. >>   S22=017  S23=019  S24=150  S25=005  S26=001  S27=001  S28=008  S29=020
  57. >>   S31=000  S32=009  S33=000  S34=000  S35=000  S36=000  S37=000  S38=000
  58. >>   S39=010  S40=000  S41=000  S42=126  S43=200  S44=015  S51=000  S53=000
  59. >>   S54=064  S55=000  S56=000  S57=000
  60. >>
  61. >>   Product type           International External MSK
  62. >>   Options                HST,V32bis,Terbo,V.FC,V.34
  63. >>   Fax Options            Class 1/Class 2.0
  64. >>   Clock Freq             20.16Mhz
  65. >>   Eprom                  256k
  66. >>   Ram                    32k
  67. >>
  68. >>   Supervisor date        08/12/94
  69. >>   DSP date               08/02/94
  70. >>
  71. >>   Supervisor rev         6.0
  72. >>   DSPPro rev                11.1
  73. >>
  74. >>  >>
  75. >>
  76. >>---
  77. > I must take you to task for the subject line.  Your modem which you
  78. > illustrated is not a v.everything modem.  It is an older Dual Standard
  79. > v.34 modem.  The SDL is very dated.  I am sure that a newer firmware
  80. > exists than Aug 12 1994.
  81.  
  82.     OUCH, I'm suprised the modem would even work connect at all with
  83. that firmware, from waht I had heard it was pretty horrible.  The newest
  84. firmware (over a year newer then the one in use in those modems) should
  85. make a BIG improvement on ALL connections, not just those that are having
  86. problems.
  87.  
  88. > And besides USR did not state in the v.everything advertisements that
  89. > these modems would connect with all other manufactured modems.  They
  90. > only stated that the USR Courier modems would do all of the ITU-T
  91. > protocols and the Rockwell proprietary v.fc protocol.
  92.  
  93.     I certainly hope that they didn't promise that, 'cuz if they did
  94. they'd have been lieing.  USR doesn't even come close to supportign the
  95. hundreds of ITU-T protocols (most of which are in no way modem related),
  96. they don't even support half of the ITU-T v.xx protocols (they are I think
  97. 54 different v.xx protocols), in fact, they don't even support ONE more
  98. ITU-T protocol than comparable modems, and they support fewer ITU-T
  99. protocols than many modems out there (eg all 4-wire LL modems).  What
  100. these modems DO support, is both v.32terbo and vFC, neither or which are
  101. ITU-T protocols.  The Courier is the only modem to support both these
  102. protocols.  They also support HST.
  103.  
  104. > It is well known that the modems using the Rockwell chipset have a great
  105. > deal of trouble connecting even with other modems using the Rockwell
  106. > chipset.  So for brand X modems to fail to connect with the USR Courier
  107. > modems is not of any suprise to me.
  108.  
  109.     Actualy most Rockwells are fairly reliable with USRs (using
  110. current firmwares) and other Rockwells.  Problems usualy arise when you
  111. try to connect a Rockwell to an AT&T chipset modem.  For example, my
  112. Motorola Power connected to the Multitech BBS with a nice stable 28.8/28.8
  113. connection, while my Infotel (Rockwell Glue 'n Go jobbie) managed a
  114. whopping 19.2 connection, which didn't seem particularly stable, this is
  115. over the exact same phone line.
  116.  
  117. Anthony
  118.  
  119. --
  120. Anthony Hill | an171@FreeNet.Carleton.CA
  121.